به طور کلی کدهای مربوط به بدافزار در قالب‌های متفاوتی از جمله فایل‌های اجرایی، درایور و پلاگین در سیستم اجرا می‌شود و تا کنون حدود پنج ماژول مختلف با نسخه‌های متفاوت کشف شده‌اند.

با انتشار خبر کشف بدافزار "معادله" ، کار تحلیل دقیق ماژول‌های این بدافزار توسط کارشناسان پادویش آغاز شد. با بررسی‌های اولیه‌ی صورت گرفته مشخص شد طراحی و پیاده‌سازی این بدافزار نیز، هم‌چون ‌موارد پیشرفته‌ی قبلی، ماژولار است. به طور کلی کدهای مربوط به بدافزار در قالب‌های متفاوتی از جمله فایل‌های اجرایی، درایور و پلاگین در سیستم اجرا می‌شود و تا کنون حدود پنج ماژول مختلف با نسخه‌های متفاوت کشف شده‌اند.

بررسی فایل‌های مرتبط با این بدافزار نشان می‌دهد که تاریخ پیاده‌سازی آن‌ها به اوایل سال 2008 میلادی باز‌می‌گردد. هرچند تاریخ موجود در فایل‌های بسیاری از بدافزار‌ها قابل اعتماد نیست، اما استفاده‌ی بدافزار از اکسپلویت معروفی که آسیب‌پذیری آن در نسخه‌های بعد از ویندوز xp برطرف شد به ما اطمینان می‌دهد که طراحی و پیاده‌سازی ماژول‌های بدافزار به زمانی قبل از به بازار آمدن نسخه‌های بعد از ویندوز xp باز‌می‌گردد.

در قدم اول، دو ماژول EquationDrug و GrayFish به عنوان راه اندازهای اصلی ماژول‌های مراحل بعدی تشخیص داده شده و هدف تحلیل قرار گرفتند. این دو ماژول نه تنها از لحاظ عملکردی مشابه‌اند بلکه ساختار کد آن‌ها نیز بسیار به یکدیگر نزدیک است. علاوه بر‌این استفاده از درایور و موتکسی با نام یکسان توسط این دو ماژول ارتباط نزدیک طراحان آن را تایید می‌کند. نکته‌ی جالب توجه این است که اکسپلویت ذکر شده نیز توسط هر دو ماژول با اندکی تفاوت به طور مشترک مورد استفاده قرارگرفته‌است! شاید ذکر این نکته جالب‌تر باشد که همین اکسپلویت در سال‌های بعد توسط بدافزار stuxnet نیز مورد استفاده قرار‌گرفت. به همین دلیل است که وجود ارتباط میان طراحان این دو بدافزار، stuxnet و Equation، دور از انتظار نیست. علاوه‌‌بر استفاده‌ی مشترک از این اکسپلویت، آن هم در زمانی قبل از انتشار این آسیب‌پذیری در سیستم عامل ویندوز، پی‌لود‌های اجرا شده نیز اهدافی بسیار مشابه دارند.

اگر‌چه در روز‌های اخیر انتشار خبر کشف این بدافزار کارشناسان زیادی را ترغیب به تحلیل این بدافزار کرده‌است، اما هنوز هیچ تحلیل دقیقی از این بدافزار منتشر نشده‌است.

در ادامه بخش‌هایی از تحلیل دقیق این دو ماژول توسط کارشناسان پادویش ارایه می‌شود:

1- ماژول راه‌انداز EquationDrug

به طور خلاصه می‌توان گفت اجرای این ماژول در سیستم به عدم حضور برخی از دیواره‌های آتش وابسته‌است. در ادامه لیست دیواره‌های آتش مورد نظر بدافزار آمده‌است. این ماژول برای اطمینان از عدم وجود این دیواره‌های آتش از خواندن کلیه‌ی زیرکلید‌های مسیر رجیستری زیر استفاده می‌کند.

HKEY_LOCAL_MACHINE / Software

در صورت وجود هر یک از دیواره‌های آتش، EquationDrug فایل خود را قبل از اولین راه‌اندازی مجدد از بین برده و در غیر این صورت، بررسی می‌کند که دسترسی‌های لازم برای ساختن فایل و بارگذاری درایور را دارد یا خیر. در صورتی که دسترسی پایین‌تری داشته باشد با استفاده از آسیب پذیری که در win32k.sys وجود دارد، با بهره‌گیری از Privilege escalation exploit دسترسی‌های لازم را به دست می‌آورد و سپس ماژول‌های مراحل بعدی را دراپ کرده و راه‌اندازی و اجرا می‌کند.

بعد از این عملیات و اجرای کلیه‌ی فایل‌های مورد نظر، در نهایت ماژول EquationDrug با دستور قبلی اقدام به از بین بردن فایل خود قبل از اولین راه‌اندازی مجدد می‌کند.

در جدول زیر اطلاعات مربوط به کلیه‌ فایل‌های دراپ‌شده توسط این ماژول آمده‌است.

نکته‌ای که باید به آن اشاره کرد این است که کلیه‌ی کدهای مربوط به ماژول‌های مراحل بعدی و اطلاعاتی هم‌چون نام دیواره‌های آتش، همگی با الگوریتمی یکسان رمز شده و در بخش منابع، resource، ماژول EquationDrug قرار‌گرفته‌اند. این کد‌ها و اطلاعات در مراحل مختلف لود شده، رمز‌گشایی می‌شوند و مورد‌استفاده‌ی بدافزار قرار ‌می‌گیرند. علاوه بر این، این ماژول موتکسی با نام prkMtx را در سیستم می‌سازد.

2- ماژول راه‌انداز GrayFish

به طور کلی این ماژول یکی از ماژول‌های راه انداز بدافزار است که نسبت به راه انداز دیگر گروه "معادله"، EquationDrug، از ساختاری پیشرفته‌تر برخوردار‌است. با توجه به این‌که زمان کامپایل این ماژول به اوایل سال 2008 میلادی بازمی‌گردد می‌توان گفت تکنیک‌های به‌کار‌رفته در آن در زمان خود بسیار پیشرفته بوده و حتی برخی از آن‌ها برای اولین بار استفاده شده‌اند.

تقریبا تمامی رشته‌های مهم از قبیل نام API‌ها و Event‌ها، فایل‌ها و ماژول‌های دیگر به صورت رمز‌شده نگه‌داری می‌شود. علاوه بر این به غیر از بخش انتهایی برنامه که بعد از انجام عملیات دراپ کردن و راه‌اندازی موفقیت‌آمیز درایورها فرا‌می‌رسد، کد سایر بخش‌ها غیر‌مبهم و تمیز است. در واقع در بخش ابتدایی برای دشوار‌شدن روال تحلیل، برنامه به‌جای استفاده از تکنیک‌های مبهم‌سازی و چندریختی، از تکنیک هوک بهره‌برده‌است. به طور دقیق‌تر می‌توان گفت برنامه‌نویس سعی‌کرده‌است برای جلوگیری از مشخص‌شدن روال کار، با استفاده از پیگیری APIهای استفاده شده، بخشی از کد یک درایور را در کرنل هوک کند. برای رسیدن به این هدف تابع IRP_MJ_DEVICE_CONTROL مربوط به درایور Null.sys انتخاب و هوک می‌شود. این هوک با بهره گیری از یک اکسپلویت معروف پیاده‌­‍‌‌‌‌‌سازی شده­‌است که توسط بدافزار stuxnet نیز مورد استفاده قرار گرفته بود (آسیب پذیری که در win32k.sys وجود دارد، همانند ماژول قبلی). در این قسمت از توضیح دقیق روال کاری این اکسپلویت خودداری کرده­‌ایم. نکته‌­ی جالب توجه این است که علی رغم برطرف شدن این آسیب‌پذیری در ویندوزهای نسخه‌­های بالاتر، بدافزار هم‌چنان تلاش می‌کند از اکسپلویت مذکور استفاده کند.

بعد از هوک کردن این تابع، کلیه­‌ی فراخوانی‌­ها به جای فراخوانی مستقیم APIها از طریق فراخوانی این تابع صورت می­‌گیرد. برای مثال در زمان درخواست ساخت یک کلید رجیستری و یا نوشتن در آن، به جای استفاده از توابع معمول مثل RegCreateKey, RegSetValue به درایور Null.sys دستورات کنترلی ارسال می­‌شود. بنابراین می‌­توان گفت که کد فعال شده در این بخش هم‌چون یک API عمومی، GeneralAPI، عمل می‌کند. به این معنی که با توجه به کنترل کد و ورودی­‌های دریافتی تشخیص می‌­دهد که باید چه اقدامی در سیستم صورت دهد.

با توجه به توضیحات داده شده به طور خلاصه روال کار بدافزار در این بخش در سه مرحله انجام می‌­پذیرد.

مرحله­­‌ی اول: هوک کردن تابع ZwShutdownSystem

نتیجه: قرار گرفتن کد اولیه برای هوک کردن تابع IRP_MJ_DEVICE_CONTROL مربوط به درایور Null.sys

مرحله­‌ی دوم: فراخوانی تقلبی تابع ZwShutdownSystem و اجرای کد اولیه

نتیجه: قرار گرفتن کد ثانویه به عنوان API عمومی در تابع مربوطه

مرحله­‌ی سوم: فراخوانی متوالی API عمومی از طریق فراخوانی تقلبی تابع DeviceIoControl برای فایل با مسیر //.// NUL

نتیجه: انجام کلیه­‌ی فعالیت‌­های راه انداز از این طریق

لازم به ذکر است که بدافزار از API عمومی خود برای مقاصد زیر استفاده می­‌کند.

• عملیات خواندن و نوشتن کلیدهای رجیستری
• ساخت کلید رجیستری و پارامترهای آن
• خواندن و نوشتن در فایل
• ساخت فایل
• لود کردن درایورها در سیستم
• ساخت Thread

در شکل زیر می­‌توانید نمایی از ابتدای دومین پی­لود تابع را که به عنوان API عمومی عمل می­‌کند مشاهده کنید. فلش­‌های قرمز نمایشگر کدهای کنترلی‌ست که از سمت بخش کاربری به عنوان پارامتری کنترلی برای بخش کرنل ارسال شده و توسط بدافزار پشتیبانی می‌­شود.

بعد از آماده شدن API عمومی، نوبت به ایجاد فایل‌­های درایور بدافزار و لود کردن آن­ها می‌­رسد. همان­طور که در شکل نمایش داده شده است سه درایور بدافزار به نام­‌های hrilib، msndsrv و ntevt در مسیر SYSTEM32 ایجاد شده و در مرحله­‌ی بعد راه‌­اندازی می‌­شوند. علاوه بر این برای هر یک از درایورها در مسیر رجیستری زیر کلیدی با پارامترهای مربوط ساخته شده و با مقادیری که در ادامه آمده است مقداردهی می‌­شود.

* به جای نام hrilib در توضیحات رجیستری بالا می‌­تواند نام هر یک از درایورهای ساخته شده توسط راه‌انداز قرار گیرد.

توضیح این نکته ضروری به نظر می‌­رسد که استفاده از نوع LegacyDriver در ماژول‌­های درایور می­‌تواند به قدیمی بودن زمان طراحی و پیاده‌سازی این ماژول اشاره داشته باشد؛ چرا که این درایورها وابسته به طراحی legacy Windows NT بوده و از نوع Non-Plug and Play Drivers می‌­باشند.

در ادامه ماژول GrayFish از میان کلیدهای مربوط به سرویس­‌های درایوری در رجیستری دو کلید را به‌صورت تصادفی انتخاب کرده و پلاگین‌­های خود را که به فرمت رمز شده است به عنوان پارامتر در آن­ها ذخیره می­‌کند. به نظر می‌­رسد این پلاگین‌­ها در مراحل بعدی توسط سایر ماژول‌­ها مورد استفاده قرار گیرند.

یکی دیگر از موارد جالب دیده شده در روال این برنامه استفاده از تابع سند نشده‌ی RtlImageDirectoryEntryToData برای دریافت جدول Import ماژول ntkrnlpa است. با استفاده از این تابع سند نشده می‌توان اطلاعات متفاوتی را از یک فرمت PE لود شده در حافظه استخراج کرده و خواند.

در انتها نیز فایل INSTV4.BAT در مسیر زیر ساخته می­‌شود که حاوی دستور از بین بردن فایل اصلی برنامه است.

C:/Documents and Settings/***/Local Settings/Temp

بخش دیگر فایل ورژن سیستم عامل را با موارد زیر مقایسه می‌کند.

Service Pack 1

Service Pack 2, v.2055

Service Pack 2, v.2096

Service Pack 2, v.2149

Service Pack 2

Service Pack 3, v.3244

نتیجه­‌ی مقایسه‌­ی نسخه‌­ی سیستم در این مرحله تاثیری عملی بر روال کاری ماژول نخواهد داشت؛ اما این امکان وجود دارد که تغییرات ایجاد شده در پلاگین­‌ها وابسته به این موضوع باشد.

بخش انتهایی برنامه دارای کدهای مبهم است به گونه‌ای که سعی‌شده‌است به جای استفاده از فراخوانی‌ها و یا پرش‌های مشخص، آدرس بعدی اجرای کد در هر مرحله به روش‌های متفاوت ساخته‌شده و به وسیله‌ی فراخوانی‌های غیر مستقیم، رجیستری و یا دستور بازگشت ادامه‌ی برنامه اجرا شود. در شکل‌های بعدی بخش‌هایی از کد پایانی بدافزار را مشاهده می‌کنید.

1. Drop driver modules

2. Create/Write to registry key

3. Drop encrypted plugins

4. Create thread